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DETAILED ACTION 
Claim Rejections - 35 USC §102 

1 . The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the 
basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(e) the invention was described in (1) an application for patent, published under section 122(b), by another filed 
in the United States before the invention by the applicant for patent or (2) a patent granted on an application for 
patent by another filed in the United States before the invention by the applicant for patent, except that an 
international application filed under the treaty defined in section 351(a) shall have the effects for purposes of this 
subsection of an application filed in the United States only if the international application designated the United 
States and was published under Article 21(2) of such treaty in the English language. 

2. Claims 1-3,5,1 1,12,14-16,18, and 31 are rejected under 35 U.S.C. 102(e) as being 
anticipated by Buyukkoc (US 6.463.062). 

Regarding claim 1, Buyukkoc discloses an intelligent policy server (see FIG. 7-9, 
central Routing Status Database server, RDS) method in an synchronous Transfer Mode (ATM) 
network (see FIG. 7-9, ATM network; see col. 19, line 55-60) having an ingress switch (see FIG. 
9, ATM switch 922) and an egress switch (see FIG. 9, ATM switch 924), wherein said ingress 
switch serves an ingress device (see FIG. 9, switch 912) operated by a calling party (see FIG. 9, 
User 902) and said egress switch serves an egress device (see FIG. 9, Switch 914) operated by a 
called party (see FIG. 9, user 904); see col. 19, line 61 to col. 20, line 24), comprising the steps 
of: 

receiving, in said ingress switch, a signaling message from said ingress device (see FIG. 
9, step 810, edge node receive a new call; see col. 19, line 19-26; also see FIG. 10, step 
1005,1010,1015,1020,1025,1030; see col. 20, line 50-67); 

providing said signaling message to a signaling intercept processor (see FIG. 7, a link 750 
to Regional RSD server, RRSD, 740; see col. 13, line 22-46) associated with said ingress switch 
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(see col. 47 to col. 14, line 5; see FIG. 8, step 820; see col. 19, line 25-30; edge node send a call 
query/message to RSD; also see FIG. 10, step 1035); 

propagating said signaling message to a policy server (see FIG. 7, a link 770 to central 
RDS server 730, i.e., Signaling Control Point, SCP), said policy server including at least one 
policy profile associated with a plurality of policy features (see col. 14, line 9 to col. 15, line 50; 
see col. 10, line 10-20; see col. 1 1, line 1-16; see col. 13, line 1-6, 29-67; RSD contents consists 
connection rules/policy such as connectively information, threshold, quality of service, capacity, 
and/or status of loading/congestion), each policy profile of the at least one policy profile being 
associated with a subscriber (see col. 14, line 35-64; a quality of service rule/policy is one of the 
rule/policy associated with a call, where a call is associated with a user/subscriber); 

determining in said policy server, based at least in part on said signaling message, if a 
particular policy feature of the plurality of policy features is to be invoked (see FIG. 8, step 840; 
see FIG. 10, steps 1035,1040; see col. 13, line 1-7; 64 to col. 14, line 67; Tables VII-IX; decide 
how to route the call in accordance RSD contents by determining and triggering/invoking a 
particular/specific quality-of-service rule/policy of connection rules/policies for received call's 
priority of traffic); 

if so, determining whether a policy condition associated with said particular policy 
feature is satisfied with respect to said signaling message (see FIG. 8, step 840; see FIG. 10, 
steps 1035,1040; see col. 13, line 1-7; 64 to col. 14, line 67; see col. 19, line 25-40; see col. 21, 
line 19-30; determines/decides whether the load/congestion/priority/bandwidth/routes/quality-of- 
service conditions are met/fulfilled); 
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establishing a connection path between said ingress switch and said egress switch based 
on said determination that said policy condition is satisfied by said signaling message (see FIG. 
8, step 850, 860, 870; see FIG. 10, steps 1045,1050,1055; see col. 14, line 1-65; see col. 19, line 
35-50; see col. 21, line 40-50; setting/establishing the call when 
load/congestion/priority/bandwidth/routes conditions are met/fulfilled). 

Regarding claim 14, Buyukkoc discloses an Asynchronous Transfer Mode (ATM) 
network (see FIG. 7-9, ATM network; see col. 19, line 55-60) for effectuating intelligent policy 
features with respect to a call to be established between two parties (see FIG. 9, a connection 
user 904 and 902) via a virtual channel connection (see col. 20, line 1-45; a virtual circuit); see 
col. 19, line 61 to col. 20, line 24, comprising: 

an ATM switch (see FIG. 9, ATM switch 922) serving a customer premises equipment 
(CPE) operated by a party with respect to said call (see FIG. 9, CPE User 902 connects TDM 
switch 912; see col. 19, line 64 to col. 20, line 25); 

a signaling intercept processor (see FIG. 7, Regional RSD server, RRSD, 740; see col. 
13, line 22-46) associated with said ATM switch for intercepting a signaling message relative to 
said call (see col. 47 to col. 14, line 5; see FIG. 8, step 820; see col. 19, line 25-30; edge node 
send a call query/message to RSD; also see FIG. 10, step 1035); 

a policy server (see FIG. 7, central RDS server 730, i.e., Signaling Control Point, SCP) 
associated with said signaling intercept processor, said policy server including at least one policy 
profile having a plurality of policy features (see col. 14, line 9 to col. 15, line 50; see col. 10, line 
10-20; see col. 11, line 1-16; see col. 13, line 1-6, 29-67; RSD contents consists connection 
rules/policy such as connectively information, threshold, quality of service, capacity, and/or 
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status of loading/congestion), the at least one policy being associated with a subscriber (see col. 
14, line 35-64; a quality of service rule/policy is one of the rule/policy associated with a call, 
where a call is associated with a user/subscriber), wherein said policy server operates to 
effectuate a particular policy feature of the plurality of policy feature with respect to said call 
when triggered by said signaling message received from said signaling intercept processor (see 
FIG. 8, step 840; see FIG. 10, steps 1035,1040; see col. 13, line 1-7; 64 to col. 14, line 67; see 
col. 19, line 25-40; see col. 21, line 19-30; RSD determines/decides whether a particular/specific 
quality-of-service rule/policy of the load/congestion/priority^andwidth/route/quality-of-service 
condition of a new call/connection is met/fulfilled when receiving setup message from a user (via 
RRSD)). 

Regarding claims 2, 15, Buyukkoc discloses wherein said signaling message comprises 
a Connect message (see FIG. 8, step 850, a message which contains a route for new call is the 
connect message in ATM signaling/SS7; see col. 19, line 19-25, 40-45; see col 20, line 39-45). 

Regarding claims 3,5,16,18, Buyukkoc discloses wherein said signaling message 
comprises an Add Party or setup message (see FIG. 8, steps 820,830; a message which contains a 
new call requesting for a route is the SETUP/adding party message in ATM signaling/SS7; see 
col. 19, line 19-31; see col. 20, line 46-52; see col. 20, line 39-45; see col. 21, line 19-25). 

Regarding claim 11, Buyukkoc discloses an aggregated bandwidth limit feature (see col. 
17, line 30-40; see col. 13, line 45-47; total bandwidth). 

Regarding claim 12, Buyukkoc discloses a service class selection feature (see col. TO, 
line 50-55; see col. 18, line 26-45; class-of-service). 
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Regarding claim 31, Buyukkoc discloses a service class selection feature for specifying 
a service class with respect to a network port used by said party (see col. 10, line 50-55; see col. 
18, line 26-45; see FIG. 9, trunk/port 932; see col. 20, line 1-10; selecting a class-of-service for a 
port/link/trunk/circuit used by the call). 

Claim Rejections - 35 USC §103 

3. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

4. Claim 4 and 17 are rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc 
in view of Noake (US006751222B1). 

Regarding claims 4 and 17, Buyukkoc does not explicitly disclose a release message. 
However, a release message is well know in the ATM signaling/SS7 in order to disconnect the 
call. In particular, Noake teaches a release message (see FIG. 4, RELEASE message; see col. 8, 
line 9-39). Therefore, it would have been obvious to one having ordinary skill in the art at the 
time the invention was made to provide a release message, as taught by Noake in the system of 
Buyukkoc, so that it would make effective use of a band and the respective apparatus by 
transmitting connection information, and by sending/receiving a release message it will notify to 
stop the cell assembling and disassembling processes; see Noake col. 2, line 55-64; col. 8, line 
19-24. 
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5. Claims 6-9,19-21,23, and 25 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Buyukkoc in view of Christie'656 (US006690656B1). 

Regarding claims 6, 8 and 9, Buyukkoc does not explicitly disclose a source address 
validation/screening and a destination address screening. However, a source address 
validation/screening is well known in the ATM signaling/SS7. In particular, Christie'656 teaches 
a source address validation/screening and a destination address screening (see FIG. 7; see col. 7, 
line 9-19, 35-45; checking/validating caller number in ANI and verifying a dial number). 
Therefore, it would have been obvious to one having ordinary skill in the art at the time the 
invention was made to validate/verify the caller number and dial number, as taught by 
Christie'656 in the system of Buyukkoc, so that it would can validate the calls and generate a 
billing record; see Christie'656 col. 3, line 12-22; col. 7, line 39-45. 

Regarding claim 19, Buyukkoc discloses accessing said ATM network through a 
particular network port associated with said CPE (see FIG. 9, accessing Switch 922 through the 
trunk/port 932; see col. 20, line 1-10). 

Buyukkoc does not explicitly disclose a source address validation for ensuring that said 
party is an authorized party for accessing the network. 

However, a source address validation for ensuring that said party is an authorized party 
for accessing the network is well known in the art of signaling in order to established the call. In 
particular, Christie'656 teaches a source address validation for ensuring that said party is an 
authorized party for accessing the ATM network (see FIG. 7; see col. 7, line 9-19, 35-45; 
checking/validating caller number in ANI for verification for accessing ATM network). 
Therefore, it would have been obvious to one having ordinary skill in the art at the time the 
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invention was made to validate/verify the caller number to access the ATM network, as taught by 
Christie'656 in the system of Buyukkoc, so that it would can validate the calls and generate a 
billing record; see Christie'656 col. 3, line 12-22; col. 7, line 39-45. 

Regarding claim 20, Buyukkoc discloses wherein said particular network port is a 
Customer Logical Port (see col. 4, line 20-40; see col. 5, line 20-26; edge node/switch provides 
logical connection/port between customer and the network). Christie f 656 also discloses a 
Customer Logical Port (see col. 4, line 35-40; 60-67; a logical/virtual port/link). 

Regarding claim 21, Buyukkoc discloses wherein said particular network port is a full 
physical port (see FIG. 9, physical trunk/port 932; see col. 20, line 1-10). 

Regarding claim 23, Buyukkoc does not explicitly disclose a destination address 
screening for defining a plurality of address to which said party can effectuate said call. 
However, a destination address/number validation/screening for defining a plurality of 
address/numbers to which said party can effectuate said call is well known in the signaling with 
SCP. In particular, Christie'656 teaches a destination address screening for defining a plurality of 
address to which said party can effectuate said call (see FIG. 7; see col. 7, line 9-19, 35-45; see 
col. 15, line 40-60; see col. 2, line 1-15; verifying a dial number from the list of numbers where 
the call needs to be connected).- Therefore, it would have been obvious to one having ordinary 
skill in the art at the time the invention was made to validate/verify dial number from the list of 
number to establish the call, as taught by Christie'656 in the system of Buyukkoc, so that it 
would can validate the calls and generate a billing record; see Christie'656 col. 3, line 12-22; col. 
7, line 39-45. 
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Regarding claims 25, Buyukkoc does not explicitly disclose a source address screening 
for defining a plurality of address from which said call can be initiated to said party. However, a 
source address/number validation/screening for defining a plurality of address from which said 
call can be initiated to said party is well known in the signaling with SCP. In particular, 
Christie'656 teaches a source address screening for defining plurality of address from which said 
call can be initiated to said party (see FIG. 7; see col. 7, line 9-19, 35-45; see col. 15, line 40-60; 
see col. 2, line 1-15; verifying a caller number, from the list of numbers, to initiate a 
call/connection). Therefore, it would have been obvious to one having ordinary skill in the art at 
the time the invention was made to validate/verify caller number from the list of number to 
initiate a call, as taught by Christie'656 in the system of Buyukkoc, so that it would can validate 
the calls and generate a billing record; see Christie'656 col. 3, line 12-22; col. 7, line 39-45. 

6. Claims 7 and 22 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Buyukkoc in view of Farris (US006 154445 A). 

Regarding claim 7, Buyukkoc does not explicitly disclose a maximum call attempt rate 
limit. However, having a maximum call attempt rate limit/threshold is well known in the 
signaling/SS7. In particular, Farris teaches a maximum call attempt rate limit (see col. 14, line 1- 
12; see col. 11, line 5-17; acceptable/maximum specified rate of call attempts). Therefore, it 
would have been obvious to one having ordinary skill in the art at the time the invention was 
made to provide acceptable/maximum specified rate of call attempts, as taught by Farris in the 
system of Buyukkoc, so that it would can detect the predetermined events and/or imminence of 
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predetermined events, and then blocking or controlling those events from their incipiency; see 
Farris col. 14, line 1-6. 

Regarding claim 22, Buyukkoc discloses the number of setup messages as described 
above in claim 18. 

Buyukkoc does not explicitly disclose a maximum call attempt rate limit for monitoring 
the number of messages received from said party over a predetermined period of time. However, 
having a maximufn call attempt rate limit for monitoring the number of messages received from 
said party over a predetermined period of time is well known in the art of signaling and network 
management. In particular, Farris teaches a maximum call attempt rate limit for monitoring the 
number of setup messages received from said party over a predetermined period of time (see col. 
14, line 1-12; see col. 11, line 5-56; acceptable/maximum specified rate of call attempts for 
monitoring and determining the number of setup/ISUP messages from calling party per time 
period). Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide acceptable/maximum specified rate of call attempts and 
monitoring process, as taught by Farris in the system of Buyukkoc, for the same motivation as 
stated above in claim 7. 

7. Claim 10 is rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc in 
view of VanDervort (US005761 191 A), or Horn (US005276676A). 

Regarding claim 10, Buyukkoc discloses a policy feature comprises a maximum size 
limit feature (see col. 14, line 15-65; acceptable/maximum load/size/band width before the call 
are blocked). 
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Buyukkoc does not explicitly disclose burst. However, ATM network having a 
rule/policy/policing attribute burst size threshold/limiting for ATM flow control is well known in 
the art. In particular, VanDervort teaches a maximum burst size limit/threshold feature (see col. 
6, line 8-11; limited/maximum burst size limit/threshold of user cell transmission for policing). 
Therefore, it would have been obvious to one having ordinary skill in the art at the time the 
invention was made to provide limited/maximum burst size, as taught by VanDervort in the 
system of Buyukkoc, so that it would control the flow of traffic and maximize the utilization of* 
network resources; see VanDervort col. 6, line 1-3. 

Buyukkoc does not explicitly disclose burst. In particular, Horn teaches a maximum burst 
» size limit/threshold feature (see col. 2, line 29-30; maximum burst length is limited by 

threshold). Therefore, it would have been obvious to one having ordinary skill in the art at the 
time the invention was made to provide maximum burst length threshold, as taught by Horn in 
the system of Buyukkoc, so that it would avoid overflow problem due to long bursts; see Horn 
col. 1, line 25-34. 

8. Claims 13 and 38 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Buyukkoc in view of Basso (US006633539B1). 

Regarding claim 13, Buyukkoc discloses a policy feature comprises a maximum call 
limit feature (see col. 14, line 15-65; acceptable/maximum call load/limit/bandwidth). 

Buyukkoc does not explicitly disclose concurrent. However, ATM network having a 
maximum concurrent call limit/threshed for call admission control (CAC) is well known in the 
art. In particular, Basso teaches a maximum concurrent call limit feature (see col. 4, line 25-35; 



Application/Control Number: 09/766,943 Page 12 

Art Unit: 2616 

maximum allowed/limit number of concurrent connection/call). Therefore, it would have been 
obvious to one having ordinary skill in the art at the time the invention was made to provide 
maximum concurrent connection, as taught by Basso in the system of Buyukkoc, so that it would 
control concurrent connections/calls to provide efficient protection against signaling congestion; 
see Basso col. 2, line 35-45. 

Regarding claim 38, Buyukkoc discloses a policy feature comprise a maximum call 
limit feature for specifying the total number of calls allowed concurrently with respect to a 
network port used by said party (see col. 14, line 10 to col. 15, line 50; see FIG. 9, trunk/port 
932; see col. 20, line 1-10; acceptable/allowable total number of calls threshold/limit for a 
trunk/port). 

Buyukkoc does not explicitly disclose concurrent. However, ATM network having a 
maximum concurrent call limit/threshed for call admission control (CAC) is well known in the 
art. In particular, Basso teaches a maximum concurrent call limit feature (see col. 4, line 25-35; 
maximum allowed/limit number of concurrent connection/call). Therefore, it would have been 
obvious to one having ordinary skill in the art at the time the invention was made to provide 
maximum concurrent connection, as taught by Basso in the system of Buyukkoc, so that it would 
control concurrent connections/calls to provide efficient protection against signaling congestion; 
see Basso col. 2, line 35-45. 

9. Claim 24 and 26 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Buyukkoc in view of Christie'656, as set forth above in claim 14, and further in view of Gai 
(US006 167445 A). 
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Regarding claim 24, the combined of Buyukkoc and Christie'656 discloses destination 
address screening feature is established for a subscriber to which said party belongs as set forth 
above in claim 23. 

Neither Buyukkoc nor Gai explicitly discloses a group of subscribers. However, Gai 
teaches a policy server (see FIG. 4, policy server 322) comprising the particular policy feature 
(see FIG. 4, Policy Rule generation engine 414, policy translator 410, and device-specific 
filtering entity; see col. 13, line 61 to col. 14, line 5) including at least one of a destination 
screening feature for a group of subscribers to which the party belongs (see col. 14, line 1-15, 56 
to col. 15, line 55; applying destination addressing policy rule to a group of users (see FIG. 7A, 
marking users, admin users, executive users, etc.) where a specific user (see FIG. 7A, John Doe) 
belongs; see col. see col. 14, line 10-18). Therefore, it would have been obvious to one having 
ordinary skill in the art at the time the invention was made to provide a destination screening 
feature for a group of subscribers to which the party belongs, as taught by Gai in the combined 
system of Buyukkoc and Christie'565, so that it would ability to allocate network services and 
resources by applying high-level quality of service policies; see Gai col. 5, line 45-55. 

Regarding claim 26, the combined of Buyukkoc and Christie'656 discloses source 
address screening feature is established for a subscriber to which said party belongs as set forth 
above in claim 25. 

Neither Buyukkoc nor Christie'656 explicitly discloses a group of subscribers. However, 
Gai teaches a policy server (see FIG. 4, policy server 322) comprising the particular policy 
feature (see FIG. 4, Policy Rule generation engine 414, policy translator 410, and device-specific 
filtering entity; see col. 13, line 61 to col. 14, line 5) including a source address screening feature 
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for the group of subscribers to which the party belongs (see col. 14, line 1-15, 56 to col. 15, line 
55; applying source addressing policy rule to a group of users (see FIG. 7 A, marking users, 
admin users, executive users, etc.) where a specific user (see FIG. 7A, John Doe) belongs; see 
col. see col. 14, line 10-18). Therefore, it would have been obvious to one having ordinary skill 
in the art at the time the invention was made to provide a source address screening feature for the 
group of subscribers to which the party belongs, as taught by Gai in the combined system of 
Buyukkoc and Christie' 656, so that it would ability to allocate network services and resources by 
applying high-level quality of service policies; see Gai col. 5, line 45-55. 

10. Claims 27-29 are rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc 
in view of Kobayashi (US 5,896,371). 

Regarding claims 27, Buyukkoc discloses a maximum burst size limit feature associated 
with said call (see col. 14, line 15-65; acceptable/maximum load/size before the call are 
blocked). 

Buyukkoc does not explicitly disclose limiting a burst-size request. However, limiting a 
burst-size request is well known in the art of ATM. In particular, Kobayashi teaches a maximum 
burst size limit feature for limiting a burst-size request associated with said call (see FIG. 6; see 
col. 12, line 55 to col. 13, line 35; a limiting/setting/changing the number of cells transmitted in 
each call). Therefore, it would have been obvious to one having ordinary skill in the art at the 
time the invention was made to limit the number of cells transmitted in each call, as taught by 
Kobayashi in the system of Buyukkoc, so that it would provide a flow control performed 
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cooperatively by the network and the terminal equipment and call accepted control is simplified; 
see Kobayashi col. 7, line 46-52; col 8, line 40-45. 

Regarding claim 28, Kobayashi discloses the number of packets per second allowed to 
be transmitted to said ATM network with respect to said call (see FIG. 6; see col. 12, line 55 to 
col. 13, line 35; a number of cells per second (i.e. 10Mbps) requested to transmit in each call to 
ATM network). Therefore, it would have been obvious to one having ordinary skill in the art at 
the time the invention was made to provide the number of packets per second requested to be 
transmitted, as taught by Kobayashi in the system of Buyukkoc, for the same motivation as 
above in claim 27. 

Regarding claim 29, Kobayashi discloses the number of packets per second allowed to 
be received by said party from said ATM network with respect to said call (see FIG. 6; see col. 
12, line 55 to col. 13, line 35; a number of cells per second (i.e. 10Mbps) requested to received in 
each call from ATM network). Therefore, it would have been obvious to one having ordinary 
skill in the art at the time the invention was made to provide the number of packets per second 
requested to be received, as taught by Kobayashi in the system of Buyukkoc, for the same 
motivation as above in claim 27. 

11. Claim 30 is rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc in 
view of Smith (US006222823B1). 

Regarding claim 30, Buyukkoc discloses an aggregated bandwidth limit feature for a 
particular network port by said party (see FIG. 9, physical trunk/port 932; see col. 20, line 1-10; 
col. 17, line 30-40; see col. 13, line 45-47; total bandwidth for the port/link). 
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Buyukkoc does not explicitly disclose for determining a maximum bandwidth allowable 
and authorized for use. However, determining the maximum bandwidth allowable for a particular 
port authorized for use by said party is well known in the art of ATM. In particular, Smith 
teaches determining the maximum bandwidth allowable for a particular port authorized for use 
by said party (see FIG. 1-2; see col. 9, line 5-45, and abstract; determining 
predetermined/allowable/authorized bandwidth for a particular port/connection of end station). 
Therefore, it would have been obvious to one having ordinary skill in the art at the time the 
invention was made to determining predetermined/allowable/authorized bandwidth for a 
particular port/connection of end station, as taught by Smith in the system of Buyukkoc, so that it 
would cause the system control means to allocate a predetermined bandwidth and balance the 
bandwidth; see Smith col. 2, line 35-67; col. 9, line 21-25. 

12. Claims 32-37 are rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc 
in view of Kilkki (US006041039A). 

Regarding claims 32-37, Buyukkoc discloses service class as described above in claim 
31 and 58. Buyukkoc further discloses constant bit rate service (CBR) and variable bit rate 
service (VBR) (see col. 1, line 50-60). 

Buyukkoc does not explicitly disclose a real-time VBR service, non-real time VBR, 
unspecified bit-rate (UBR), and available bit-rate (ABR). However, the ATM class of services a 
real-time VBR service, non-real time VBR, unspecified bit-rate (UBR), and available bit-rate 
(ABR) is well known in ATM standard. In particular, Kilkki teaches CBR, VBR, a real-time 
VBR service, non-real time VBR, unspecified bit-rate (UBR), and available bit-rate (ABR) (see 
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col. 1 5 line 54-67). Therefore, it would have been obvious to one having ordinary skill in the art 
at the time the invention was made to provide quality of service class defined by ATM standard, 
as taught by Kilkki in the system of Buyukkoc, so that it would provide a capability to manage 
increases in network load, supporting both real-time and non-real time application, and offering, 
in certain circumstances, a guaranteed level service quality; see Kilkki col. 1, line 44-53, also by 
using the ATM standard services, it will enable the service provider to interoperate between 
multi- vendor networks. 

13. Claim 39,40-43,45,50 and 58 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Buyukkoc in view of Gai (US006 1 67445 A). 

Regarding claim 39, Buyukkoc discloses a computer-readable medium operable with an 
Asynchronous Transfer Mode (ATM) network node (see FIG. 9, ATM switch 922,924), said 
computer-readable medium carrying a sequence of instructions provided for executing service 
logic which, when executed by a processing entity associated with said ATM network node, 
causes said ATM network node to perform the steps of: 

upon receiving in said ATM network node a signaling message with respect to a call 
from a party (see FIG. 9, User 902); see FIG. 9, step 810, edge node receive a new call; see col. 
19, line 19-26; also see FIG. 10, step 1005,1010,1015,1020,1025,1030; see col. 20, line 50-67), 
propagating said signaling message to a policy server (see FIG. 7-9, central Routing Status 
Database server, RDS) operably associated with said ATM network node (see FIG. 7, a link 770 
to central RDS server 730, i.e., Signaling Control Point, SCP); and 

upon determining that a policy condition associated with a particular policy feature to be 
invoked is satisfied with respect to said signaling message (see FIG. 8, step 840; see FIG. 10, 
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steps 1035,1040; see col. 13, line 1-7; 64 to col. 14, line 67; Tables VII-IX; decide how to route 
the call in accordance RSD contents by determining and triggering/invoking a particular/specific 
quality-of-service rule/policy of connection rules/policies for received call's priority of traffic), 
effectuating a treatment for said call based on said particular policy feature (see FIG. 8, step 850, 
860, 870; see FIG. 10, steps 1045,1050,1055; see col. 14, line 1-65; see col. 19, line 35-50; see 
col. 21, line 40-50; setting/establishing the call when load/congestion/priority/bandwidth/routes 
conditions are met/fulfilled (i.e. carrying/effectuating a action/treatment (by setting/establishing 
a call) when load/congestion/priority/bandwidth/routes conditions are met/fulfilled)).). 

Buyukkoc does not explicitly disclose one of a destination screening feature for a group 
of subscribers to which the party belongs or a source address screening feature for the group of 
subscribers. However, Gai teaches a policy server (see FIG. 4, policy server 322) comprising the 
particular policy feature (see FIG. 4, Policy Rule generation engine 414, policy translator 410, 
and device-specific filtering entity; see col. 13, line 61 to col. 14, line 5) including at least one of 
a destination screening feature for a group of subscribers to which the party belongs or a source 
address screening feature for the group of subscribers (see col. 14, line 1-15, 56 to col. 15, line 
55; applying source or destination addressing policy rule to a group of users (see FIG. 7 A, 
marking users, admin users, executive users, etc.) where a specific user (see FIG. 7A, John Doe) 
belongs; see col. see col. 14, line 10-18). Therefore, it would have been obvious to one having 
ordinary skill in the art at the time the invention was made to provide one of a destination 
screening feature for a group of subscribers to which the party belongs or a source address 
screening feature for the group of subscribers, as taught by Gai in the system of Buyukkoc, so 
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that it would ability to allocate network services and resources by applying high-level quality of 
service policies; see Gai col. 5, line 45-55. 

Regarding claims 40, Buyukkoc discloses establishing a virtual channel connection 
between said party and another party for said call (see col. 20, line 5-45; virtual connection 
between users). 

Regarding claims 41, Buyukkoc discloses denying a virtual channel connection for said 
call (see col. 14, line 44-47; see col. 1 5 line 66-67; call is block, thereby, blocking the virtual 
connection due to congestion). 

Regarding claim 42, Buyukkoc discloses wherein said signaling message comprises a 
Connect message (see FIG. 8, step 850, a message which contains a route for new call is the 
connect message in ATM signaling/SS7; see col. 19, line 19-25, 40-45; see col. 20, line 39-45). 

Regarding claims 43 and 45, Buyukkoc discloses wherein said signaling message 
comprises an Add Party or setup message (see FIG. 8, steps 820,830; a message which contains a 
new call requesting for a route is the SETUP/adding party message in ATM signaling/SS7; see 
col. 19, line 19-31; see col. 20, line 46-52; see col. 20, line 39-45; see col. 21, line 19-25). 

Regarding claim 50, the combined system of Buyukkoc and Gai discloses all limitation 
as set forth above in claim 39. Gai disclose a destination address screening and source address 
screening feature (see col. 14, line 1-15, 56 to col. 15, line 55; applying source and destination 
addressing policy rule; see col. see col. 14, line 10-18). Therefore, it would have been obvious to 
one having ordinary skill in the art at the time the invention was made to provide a destination 
screening feature and a source address screening feature, as taught by Gai in the system of 
Buyukkoc, for the same motivation as set forth above in claim 39. 
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Regarding claim 58, Buyukkoc discloses a service class selection feature for specifying 
a service class with respect to a network port used by said party (see col. 10, line 50-55; see col 
18, line 26-45; see FIG. 9, trunk/port 932; see col. 20, line 1-10; selecting a class-of-service for a 
port/link/trunk/circuit used by the call). 

14. Claim 44 is rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc in 
view of Gai, as set forth in claim 39 above, and further in view of Noake (US006751222B1). 

Regarding claim 44, neither Buyukkoc nor Gai explicitly disclose a release message. 
However, a release message is well know in the ATM signaling/SS7 in order to disconnect the 
call. In particular, Noake teaches a release message (see FIG. 4, RELEASE message; see col. 8, 
line 9-39). Therefore, it would have been obvious to one having ordinary skill in the art at the 
time the invention was made to provide a release message, as taught by Noake in the combined 
system of Buyukkoc and Gai, so that it would make effective use of a band and the respective 
apparatus by transmitting connection information, and by sending/receiving a release message it 
will notify to stop the cell assembling and disassembling processes; see Noake col. 2, line 55-64; 
col. 8, line 19-24. 

15. Claims 46-48 are rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc 
in view of Gai, as set forth in claim 39 above, and further in view of Christie f 656 
(US006690656B1). 

Regarding claim 46, Buyukkoc discloses accessing said ATM network through a 
particular network port associated with said CPE (see FIG. 9, accessing Switch 922 through the 
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trunk/port 932; see col. 20, line 1-10). Gai discloses source address screening feature as set forth 
above in claim 39. 

Neither Buyukkoc nor Gai explicitly disclose ensuring that said party is an authorized 
party for accessing the network. 

However, a source address validation for ensuring that said party is an authorized party 
for accessing the network is well known in the art of signaling in order to established the call. In 
particular, Christie'656 teaches a source address validation for ensuring that said party is an 
authorized party for accessing the ATM network (see FIG. 7; see col. 7, line 9-19, 35-45; 
checking/validating caller number in ANI for verification for accessing ATM network). 
Therefore, it would have been obvious to one having ordinary skill in the art at the time the 
invention was made to validate/verify the caller number to access the ATM network, as taught by 
Christie'656 in the combined system of Buyukkoc and Gai, so that it would can validate the calls 
and generate a billing record; see Christie'656 col. 3, line 12-22; col. 7, line 39-45. 

Regarding claim 47, Buyukkoc discloses wherein said particular network port is a 
Customer Logical Port (see col. 4, line 20-40; see col. 5, line 20-26; edge node/switch provides 
logical connection/port between customer and the network). Christie'656 also discloses a 
Customer Logical Port (see col. 4, line 35-40; 60-67; a logical/virtual port/link). 

Regarding claim 48, Buyukkoc discloses wherein said particular network port is a full 
physical port (see FIG. 9, physical trunk/port 932; see col. 20, line 1-10). 

16. Claim 49 is rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc in 
view of Gai, as set forth above in claim 39, and further in view of Farris (US006 154445 A). 
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Regarding claim 49, Buyukkoc discloses the number of setup messages (see FIG. 8, 
steps 820,830; a message which contains a new call requesting for a route is the SETUP/adding 
party message in ATM signaling/SS7; see col. 19, line 19-31; see col. 20, line 46-52; see col. 20, 
line 39-45; see col. 21, line 19-25). 

Neither Buyukkoc nor Gai explicitly disclose a maximum call attempt rate limit for 
monitoring the number of messages received from said party over a predetermined period of 
time. However, having a maximum call attempt rate limit for monitoring the number of messages 
received from said party over a predetermined period of time is well known in the art of 
signaling and network management. In particular, Farris teaches a maximum call attempt rate 
limit for monitoring the number of setup messages received from said party over a predetermined 
period of time (see col. 14, line 1-12; see col. 11, line 5-56; acceptable/maximum specified rate 
of call attempts for monitoring and determining the number of setup/ISUP messages from calling 
party per time period). Therefore, it would have been obvious to one having ordinary skill in the 
art at the time the invention was made to provide acceptable/maximum specified rate of call 
attempts and monitoring process, as taught by Farris in the combined system of Buyukkoc and 
Gai, so that it would can detect the predetermined events and/or imminence of predetermined 
events, and then blocking or controlling those events from their incipiency; see Farris col. 14, 
line 1-6. 

17. Claim 65 is rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc in 
view of Gai, as set forth above in claim 39, and further in view of Basso (US006633539B1). 
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Regarding claim 65, Buyukkoc discloses a policy feature comprise a maximum call 
limit feature for specifying the total number of calls allowed concurrently with respect to a 
network port used by said party (see col. 14, line 10 to col. 15, line 50; see FIG. 9, trunk/port 
932; see col. 20, line 1-10; acceptable/allowable total number of calls threshold/limit for a 
trunk/port). 

Neither Buyukkoc nor Gai explicitly disclose concurrent. However, ATM network 
having a maximum concurrent call limit/threshed for call admission control (CAC) is well 
known in the art. In particular, Basso teaches a maximum concurrent call limit feature (see col. 4, 
line 25-35; maximum allowed/limit number of concurrent connection/call). Therefore, it would 
have been obvious to one having ordinary skill in the art at the time the invention was made to 
provide maximum concurrent connection, as taught by Basso in the combined system of 
Buyukkoc and Gai, so that it would control concurrent connections/calls to provide efficient 
protection against signaling congestion; see Basso col. 2, line 35-45. 

18. Claims 54-56 are rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc 
in view of Gai, as set forth in claim 39 above, and further in view of Kobayashi (US 5,896,371). 

Regarding claim 54, Buyukkoc discloses a maximum burst size limit feature associated 
with said call (see col. 14, line 15-65; acceptable/maximum load/size before the call are 
blocked). 

Neither Buyukkoc nor Gai explicitly disclose limiting a burst-size request. However, 
limiting a burst-size request is well known in the art of ATM. In particular, Kobayashi teaches a 
maximum burst size limit feature for limiting a burst-size request associated with said call (see 
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FIG. 6; see col. 12, line 55 to col. 13, line 35; a limiting/setting/changing the number of cells 
transmitted in each call). Therefore, it would have been obvious to one having ordinary skill in 
the art at the time the invention was made to limit the number of cells transmitted in each call, as 
taught by Kobayashi in the combined system of Buyukkoc and Gai, so that it would provide a 
flow control performed cooperatively by the network and the terminal equipment and call 
accepted control is simplified; see Kobayashi col. 7, line 46-52; col. 8, line 40-45. 

Regarding claim 55, Kobayashi discloses the number of packets per second allowed to 
be transmitted to said ATM network with respect to said call (see FIG. 6; see col. 12, line 55 to 
col. 13, line 35; a number of cells per second (i.e. 10Mbps) requested to transmit in each call to 
ATM network). Therefore, it would have been obvious to one having ordinary skill in the art at 
the time the invention was made to provide the number of packets per second requested to be 
transmitted, as taught by Kobayashi in the combined system of Buyukkoc and Gai, for the same 
motivation as above in claim 54. 

Regarding claim 56, Kobayashi discloses the number of packets per second allowed to 
be received by said party from said ATM network with respect to said call (see FIG. 6; see col. 
12, line 55 to col. 13, line 35; a number of cells per second (i.e. 10Mbps) requested to received in 
each call from ATM network). Therefore, it would have been obvious to one having ordinary 
skill in the art at the time the invention was made to provide the number of packets per second 
requested to be received, as taught by Kobayashi in the combined system of Buyukkoc and Gai, 
for the same motivation as above in claim 54. 

19. Claim 57 is rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc in 
view of Gai, as set forth in claim 39, and further in view of Smith (US006222823B1). 
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Regarding claim 57, Buyukkoc discloses an aggregated bandwidth limit feature for a 
particular network port by said party (see FIG. 9, physical trunk/port 932; see col. 20, line 1-10; 
col. 17, line 30-40; see col. 13, line 45-47; total bandwidth for the port/link). 

Neither Buyukkoc nor Gai explicitly disclose for determining a maximum bandwidth 
allowable and authorized for use. However, determining the maximum bandwidth allowable for 
a particular port authorized for use by said party is well known in the art of ATM. In particular, 
Smith teaches determining the maximum bandwidth allowable for a particular port authorized for 
use by said party (see FIG. 1-2; see col. 9, line 5-45, and abstract; determining 
predetermined/allowable/authorized bandwidth for a particular port/connection of end station). 
Therefore, it would have been obvious to one having ordinary skill in the art at the time the 
invention was made to determining predetermined/allowable/authorized bandwidth for a 
particular port/connection of end station, as taught by Smith in the combined system of 
Buyukkoc and Gai, so that it would cause the system control means to allocate a predetermined 
bandwidth and balance the bandwidth; see Smith col. 2, line 35-67; col. 9, line 21-25. 

20. Claims 59-64 are rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc 
in view of Gai, as set forth in claim 39, and further in view of Kilkki (US006041039A). 

Regarding claims 59-64, Buyukkoc discloses service class as described above in claim 
31 and 58. Buyukkoc further discloses constant bit rate service (CBR) and variable bit rate 
service (VBR) (see col. 1, line 50-60). 

Neither Buyukkoc nor Gai explicitly disclose a real-time VBR service, non-real time 
VBR, unspecified bit-rate (UBR), and available bit-rate (ABR). However, the ATM class of 
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services a real-time VBR service, non-real time VBR, unspecified bit-rate (UBR), and available 
bit-rate (ABR) is well known in ATM standard. In particular, Kilkki teaches CBR, VBR, a real- 
time VBR service, non-real time VBR, unspecified bit-rate (UBR), and available bit-rate (ABR) 
(see col. 1, line 54-67). Therefore, it would have been obvious to one having ordinary skill in the 
art at the time the invention was made to provide quality of service class defined by ATM 
standard, as taught by Kilkki in the combined system of Buyukkoc and Gai, so that it would 
provide a capability to manage increases in network load, supporting both real-time and non-real 
time application, and offering, in certain circumstances, a guaranteed level service quality; see 
Kilkki col. 1, line 44-53, also by using the ATM standard services, it will enable the service 
provider to intemperate between multi-vendor networks. 

Response to Arguments 
21. Applicant's arguments filed 1 1-16-2006 have been fully considered but they are not 
persuasive. 

Regarding claims 1-50,54-65, the applicant argued that, "...Buyukkoc does not 
disclose or suggest propagation a signaling message to a policy server, where the policy server 
includes at least one policy profile having a plurality of policy features, and where each policy 
profile of the at least one policy profile is associated with a subscriber. . .nowhere in Buyukkoc 
discloses or suggest that routing status database includes at least at least one policy profile 
having a plurality of policy features, and where each policy profile of the at least one policy 
profile is associated with a subscriber. . .Buyukkoc does not even mention policy profiles. . . 55 in 
page 27-33. 
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In response to applicant's argument, the examiner respectfully disagrees with the 
argument above. Buyukkoc discloses propagating said signaling message (see FIG. 8, Step 820; 
see FIG. 10, step 1030; sends setup for a new call to RSD) to a policy server (see FIG. 7, a 
link 770 to central RDS server 730, i.e., Signaling Control Point, SCP), said policy server 
including at least one policy profile having a plurality of policy features (see col. 14, line 9 to 
col. 15, line 50; see col. 10, line 10-20; see col. 11, line 1-16; see col. 13, line 1-6, 29-67; RSD 
contents consists connection rules/policy such as connectively information, threshold, 
quality of service, capacity, and/or status of loading/congestion), and where each policy 
profile of the at least one policy profile being associated with a subscriber (see col. 14, line 35- 
64; a quality of service rule/policy is one of the rule/policy associated with a call, where a 
call is associated with a user/subscriber). 

Examiner asserts applicant's policy sever as Buyukkoc 's RSD (see general response 
below). Also, examiner asserts applicant's "at least one policy profile" as Buyukkoc's "quality 
of service priority of a request call" (see general response below). 

Regarding claim 11, the applicant argued that, ". . .Buyukkoc teaches away from this 
feature. . .Buyukkoc does not discloses or suggest. . . a particular policy feature comprising an 
aggregate bandwidth limit feature. . in page 33-35. 

In response to applicant's argument, the examiner respectfully disagrees with the 
argument above. Buyukkoc discloses an aggregated bandwidth limit feature (see col. 17, line 30- 
40; see col. 13, line 45-47; total bandwidth). As recited above, claim 1 1 broadly recites, 
"aggregate bandwidth limit", and there no specific detailed of how "aggregate bandwidth limit" 
is determined, computed, or how such bandwidth is stored are being claimed. Thus, Buyukkoc 
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does not teach away from the applicant's invention of broadly cited "aggregate bandwidth limit" 
since Buyukkoc clearly teaches utilizing "total bandwidth" as a rule/policy for connection. 
Although the claims are interpreted in light of the specification, limitations from the specification 
are not read into the claims. See In re Van Geuns, 988 F.2d 1 181, 26 USPQ2d 1057 (Fed. Cir. 
1993). 

Regarding claims 4 and 17, the applicant argued that, "...Noake is no way discloses 
or suggest. . .transmission of a Release message. . .to a policy server. . .one skilled in the art would 
not have been motivated to incorporated this alleged feature into the Buyukkoc system, absent 
impermissible hindsight..." in page 35-38. 

In response to applicant's argument, the examiner respectfully disagrees with the 
argument above. Regarding argument with respect to policy server, please see above response 
since the combined system of Buyukkoc and Noake "as a whole" discloses applicant claimed 
invention. Buyukkoc discloses a signaling message as set forth above. It is also well known and 
established in the art and fundamental step in telecommunication that when disconnecting a 
call/connection, the singling system (i.e. ATM signaling/SS7) release allocated resources by 
transmission of a Release message so that such recourses can be reallocated to other users for 
other calls/connections. In particular, Noake simply further discloses a signaling message of 
Buyukkoc as a specific "Release message" (see Noake FIG. 4, RELEASE message; see col. 8, 
line 9-39). Therefore, it would have been obvious to one having ordinary skill in the art at the 
time the invention was made to provide a release message, as taught by Noake in the system of 
Buyukkoc, so that it would make effective use of a band and the respective apparatus by 
transmitting connection information, and by sending/receiving a release message it will notify to 
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stop the cell assembling and disassembling processes; see Noake col. 2, line 55-64; col. 8, line 
19-24. 

In response to applicant's argument that one would not be motivated to incorporate 
this alleged feature into Buyukkoc, the test for obviousness is not whether the features of a 
secondary reference may be bodily incorporated into the structure of the primary reference; nor 
is it that the claimed invention must be expressly suggested in any one or all of the references. 
Rather, the test is what the combined teachings of the references would have suggested to those 
of ordinary skill in the art. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981). 

In response to applicant's argument that the examiner's conclusion of obviousness is 
based upon improper hindsight reasoning, it must be recognized that any judgment on 
obviousness is in a sense necessarily a reconstruction based upon hindsight reasoning. But so 
long as it takes into account only knowledge which was within the level of ordinary skill at the 
time the claimed invention was made, and does not include knowledge gleaned only from the 
applicant's disclosure, such a reconstruction is proper. See In re McLaughlin, 443 F.2d 1392, 
170 USPQ 209 (CCPA 1971). 

Regarding claims 6, 8 and 9, the applicant argued that, . .Christie for allegedly 
disclosing a source/destination address validation/screening and destination address screening. 
Applicants submit that Examiner's allegation does not address the specifically recited features of 
claims.. .examiner does not alleged, and Christie does not disclose or suggest, a policy 
server... thus examiner has not established a prima facie case of obviousness . . .motivation 
statement does not satisfy requirement of 35 USC 103... Buyukkoc does not disclose or suggest a 
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desire to change the routing status database server... examiner's motivation is based on 
impermissible hindsight..." in page 39-44. 

In response to applicant's argument, the examiner respectfully disagrees with the 
argument above. 

Regarding argument with respect to policy server, please see above response since the 
combined system of Buyukkoc and Christie "as a whole" discloses applicant claimed invention. 
Buyukkoc disclose policy/rule feature for establishing a connection. Source and destination 
addresses validation/screening are well known in the signaling (i.e. ATM signaling/SS7), in 
order to identify the caller validity. In particular, Christie f 656 teaches a source/destination 
address validation/screening and a destination address screening (see FIG. 7; see col. 7, line 9- 
19, 35-45; checking/validating caller number in ANI and verifying a dial number). The 
examiner recognizes that obviousness can only be established by combining or modifying the 
teachings of the prior art to produce the claimed invention where there is some teaching, 
suggestion, or motivation to do so found either in the references themselves or in the 
knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 
F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988)and/« re Jones, 958 F.2d 347, 21 USPQ2d 1941 
(Fed. Cir. 1992). In this case, it would have been obvious to one having ordinary skill in the art 
at the time the invention was made to validate/verify the caller number (i.e. source address) and 
dial number (i.e. destination address), as taught by Christie'656 in the system of Buyukkoc, so 
that it would can validate the calls and generate a billing record; see Christie'656 col. 3, line 12- 
22; col. 7, line 39-45. Moreover, as set forth above, examiner is not require to show that 
Buyukkoc disclose or suggest a desire to change the routing status database server since the 
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motivation to combine can be found " either in the references themselves or in the knowledge 
generally available to one of ordinary skill in the art". In this case, Christie clearly discloses 
the motivation, and it is also well known knowledge generally available to one of ordinary skill 
in the art, as set forth above. Thus, it is clear that examiner has established a prima facie case of 
obviousness and the above motivation statement satisfy requirement of 35 USC 103. 

In response to applicant's argument that one would not be motivated to incorporate 
this alleged feature into Buyukkoc, the test for obviousness is not whether the features of a 
secondary reference may be bodily incorporated into the structure of the primary reference; nor 
is it that the claimed invention must be expressly suggested in any one or all of the references. 
Rather, the test is what the combined teachings of the references would have suggested to those 
of ordinary skill in the art. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981). 

In response to applicant's argument that the examiner's conclusion of obviousness is 
based upon improper hindsight reasoning, it must be recognized that any judgment on 
obviousness is in a sense necessarily a reconstruction based upon hindsight reasoning. But so 
long as it takes into account only knowledge which was within the level of ordinary skill at the 
time the claimed invention was made, and does not include knowledge gleaned only from the 
applicant's disclosure, such a reconstruction is proper. See In re McLaughlin, 443 F.2d 1392, 
170 USPQ 209 (CCPA 1971). 

Regarding claims 7 and 22, the applicant argued that, "...examiner's allegations that 
Farris allegedly disclosing a maximum call attempt rate limit does not address the features 
recited in claim 7. Examiner does not alleged, and Farris does not disclose or suggest, a policy 
server... thus examiner has not established a prima facie case of obviousness . . .such motivation 
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statement does not satisfy requirement of 35 USC 103. . .Buyukkoc does not disclose or suggest a 
desire to change the routing status database server... examiner's motivation is based on 
impermissible hindsight. . ." in page 45-47. 

In response to applicant's argument, the examiner respectfully disagrees with the 
argument above. 

Regarding argument with respect to policy server, please see above response since the 
combined system of Buyukkoc and Farris "as a whole" discloses applicant claimed invention. 
Having a maximum call attempt rate limit/threshold is well known in the signaling/SS7. In 
particular, Farris teaches a maximum call attempt rate limit (see col. 14, line 1-12; see col. 11, 
line 5-17; acceptable/maximum specified rate of call attempts). 

The examiner recognizes that obviousness can only be established by combining or 
modifying the teachings of the prior art to produce the claimed invention where there is some 
teaching, suggestion, or motivation to do so found either in the references themselves or in 
the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 
F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988)and In re Jones, 958 F.2d 347, 21 USPQ2d 1941 
(Fed. Cir. 1992). In this case, it would have been obvious to one having ordinary skill in the art 
at the time the invention was made to provide acceptable/maximum specified rate of call 
attempts, as taught by Farris in the system of Buyukkoc, so that it would can detect the 
predetermined events and/or imminence of predetermined events, and then blocking or 
controlling those events from their incipiency; see Farris col. 14, line 1-6. Moreover, as set forth 
above, examiner is not require to show that Buyukkoc disclose or suggest a desire to change the 
routing status database server since the motivation to combine can be found " either in the 
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references themselves or in the knowledge generally available to one of ordinary skill in the 
art". In this case, Farris clearly discloses the motivation, and it is also well known knowledge 
generally available to one of ordinary skill in the art, as set forth above. Thus, it is clear that 
examiner has established a prima facie case of obviousness and the above motivation statement 
satisfy requirement of 35 USC 103. 

In response to applicant's argument that one would not be motivated to incorporate 
this alleged feature into Buyukkoc, the test for obviousness is not whether the features of a 
secondary reference may be bodily incorporated into the structure of the primary reference; nor 
is it that the claimed invention must be expressly suggested in any one or all of the references. 
Rather, the test is what the combined teachings of the references would have suggested to those 
of ordinary skill in the art. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981). 

In response to applicant's argument that the examiner's conclusion of obviousness is 
based upon improper hindsight reasoning, it must be recognized that any judgment on 
obviousness is in a sense necessarily a reconstruction based upon hindsight reasoning. But so 
long as it takes into account only knowledge which was within the level of ordinary skill at the 
time the claimed invention was made, and does not include knowledge gleaned only from the 
applicant's disclosure, such a reconstruction is proper. See In re McLaughlin, 443 F.2d 1392, 
170 USPQ 209 (CCPA 1971). 

Regarding claim 10, the applicant argued that, "...examiner's allegations that 
VanDervort/Horn allegedly disclosing a maximum burst size limit feature does not address the 
features recited in claim 10. Examiner does not alleged, and VanDervort/Horn does not disclose 
or suggest, a policy server... thus examiner has not established a prima facie case of obviousness 
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. . .such motivation statement does not satisfy requirement of 35 USC 103. . .Buyukkoc does not 
disclose or suggest a desire to change the routing status database server... examiner's motivation 
is based on impermissible hindsight. . ." in page 48-52. 

In response to applicant's argument, the examiner respectfully disagrees with the 
argument above. 

Regarding argument with respect to policy server, please see above response since the 
combined system of Buyukkoc and VanDervort "as a whole" discloses applicant claimed 
invention. ATM network having a rule/policy/policing attribute burst size threshold/limiting for 
ATM flow control is well known in the art. In particular, VanDervort teaches a maximum burst 
size limit/threshold feature (see col. 6, line 8-11; limited/maximum burst size limit/threshold 
of user cell transmission for policing). Horn teaches a maximum burst size limit/threshold 
feature (see col. 2, line 29-30; maximum burst length is limited by threshold). 

The examiner recognizes that obviousness can only be established by combining or 
modifying the teachings of the prior art to produce the claimed invention where there is some 
teaching, suggestion, or motivation to do so found either in the references themselves or in 
the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 
F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988)and/rc re Jones, 958 F.2d 347, 21 USPQ2d 1941 
(Fed. Cir. 1992). In this case, it would have been obvious to one having ordinary skill in the art 
at the time the invention was made to provide limited/maximum burst size, as taught by 
VanDervort in the system of Buyukkoc, so that it would control the flow of traffic and maximize 
the utilization of network resources; see VanDervort col. 6, line 1-3. Also, in this case, it would 
have been obvious to one having ordinary skill in the art at the time the invention was made to 
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provide maximum burst length threshold, as taught by Horn in the system of Buyukkoc, so that it 
would avoid overflow problem due to long bursts; see Horn col. 1, line 25-34. 

Moreover, as set forth above, examiner is not require to show that Buyukkoc disclose or 
suggest a desire to change the routing status database server since the motivation to combine can 
be found " either in the references themselves or in the knowledge generally available to one 
of ordinary skill in the art". In this case, VanDervort/Horn clearly discloses the motivation, 
and it is also well known knowledge generally available to one of ordinary skill in the art, as set 
forth above. Thus, it is clear that examiner has established a prima facie case of obviousness and 
the above motivation statement satisfy requirement of 35 USC 103. 

In response to applicant's argument that one would not be motivated to incorporate 
this alleged feature into Buyukkoc, the test for obviousness is not whether the features of a 
secondary reference may be bodily incorporated into the structure of the primary reference; nor 
is it that the claimed invention must be expressly suggested in any one or all of the references. 
Rather, the test is what the combined teachings of the references would have suggested to those 
of ordinary skill in the art. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981). 

In response to applicant's argument that the examiner's conclusion of obviousness is 
based upon improper hindsight reasoning, it must be recognized that any judgment on 
obviousness is in a sense necessarily a reconstruction based upon hindsight reasoning. But so 
long as it takes into account only knowledge which was within the level of ordinary skill at the 
time the claimed invention was made, and does not include knowledge gleaned only from the 
applicant's disclosure, such a reconstruction is proper. See In re McLaughlin, 443 F.2d 1392, 
170 USPQ 209 (CCPA 1971). 
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Regarding claims 13 and 38, the applicant argued that, "...examiner's allegations that 
Basso allegedly disclosing a maximum concurrent call limit does not address the features recited 
in claim 13. Examiner does not alleged, and Basso does not disclose or suggest, a policy 
server... thus examiner has not established a prima facie case of obviousness . . .such motivation 
statement does not satisfy requirement of 35 USC 103 . . .Buyukkoc does not disclose or suggest a 
desire to change the routing status database server. . .examiner's motivation is based on 
impermissible hindsight..." in page 52-54. 

In response to applicant's argument, the examiner respectfully disagrees with the 
argument above. 

Regarding argument with respect to policy server, please see above response since the 
combined system of Buyukkoc and Basso "as a whole" discloses applicant claimed invention. 
ATM network having a maximum concurrent call limit/threshed for call admission control 
(CAC) is well known in the art. In particular, Basso teaches a maximum concurrent call limit 
feature (see col. 4, line 25-35; maximum allowed/limit number of concurrent 
connection/call). The examiner recognizes that obviousness can only be established by 
combining or modifying the teachings of the prior art to produce the claimed invention where 
there is some teaching, suggestion, or motivation to do so found either in the references 
themselves or in the knowledge generally available to one of ordinary skill in the art. See In 
re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988)and In re Jones, 958 F.2d 347, 21 
USPQ2d 1941 (Fed. Cir. 1992). In this case, it would have been obvious to one having ordinary 
skill in the art at the time the invention was made to provide maximum concurrent connection, as 
taught by Basso in the system of Buyukkoc, so that it would control concurrent connections/calls 
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to provide efficient protection against signaling congestion; see Basso col. 2, line 35-45. 
Moreover, as set forth above, examiner is not require to show that Buyukkoc disclose or suggest 
a desire to change the routing status database server since the motivation to combine can be 
found " either in the references themselves or in the knowledge generally available to one of 
ordinary skill in the art".. In this case, Basso clearly discloses the motivation, and it is also well 
known knowledge generally available to one of ordinary skill in the art, as set forth above. Thus, 
it is clear that examiner has established a prima facie case of obviousness and the above 
motivation statement satisfy requirement of 35 USC 103. 

In response to applicant's argument that one would not be motivated to incorporate 
this alleged feature into Buyukkoc, the test for obviousness is not whether the features of a 
secondary reference may be bodily incorporated into the structure of the primary reference; nor 
is it that the claimed invention must be expressly suggested in any one or all of the references. 
Rather, the test is what the combined teachings of the references would have suggested to those 
of ordinary skill in the art. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981). 

In response to applicant's argument that the examiner's conclusion of obviousness is 
based upon improper hindsight reasoning, it must be recognized that any judgment on 
obviousness is in a sense necessarily a reconstruction based upon hindsight reasoning. But so 
long as it takes into account only knowledge which was within the level of ordinary skill at the 
time the claimed invention was made, and does not include knowledge gleaned only from the 
applicant's disclosure, such a reconstruction is proper. See In re McLaughlin, 443 F.2d 1392, 
170 USPQ 209 (CCPA 1971). 
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Regarding claims 39-50,54-65, the applicant argued that, "...Buyukkoc does not 
disclose or suggest upon determining that a policy condition associated with a particular policy 
feature to be invoked is satisfied with respect to said signaling message, effectuating a treatment 
for said call based on said particular policy feature, the particular policy feature including at least 
one of a destination address screening feature for a group of subscribers to which the party 
belongs or a source address screening feature for the group of subscribers. . . one skilled in the art 
would not have been motivated to incorporate this alleged teaching for Gai into Buyukkoc, 
absent impermissible hindsight. . .such motivation statement does not satisfy requirement of 35 
USC 103..." in page 56-63. 

In response to applicant's argument, the examiner respectfully disagrees with the 
argument above. 

Buyukkoc discloses upon determining that a policy condition associated with a particular 
policy feature to be invoked is satisfied with respect to said signaling message (see FIG. 8, step 
840; see FIG. 10, steps 1035,1040; see col. 13, line 1-7; 64 to col. 14, line 67; Tables VII-IX; 
decide how to route the call in accordance RSD contents by determining and 
triggering/invoking a particular/specific quality-of-service rule/policy of connection 
rules/policies for received call's priority of traffic), effectuating a treatment for said call based 
on said particular policy feature (see FIG. 8, step 850, 860, 870; see FIG. 10, steps 
1045,1050,1055; see col. 14, line 1-65; see col. 19, line 35-50; see col. 21, line 40-50; 
setting/establishing the call when load/congestion/priority/bandwidth/routes conditions are 
met/fulfilled (i.e. carrying/effectuating a action/treatment (by setting/establishing a call) 
when load/congestion/priority/bandwidth/routes conditions are met/fulfilled)). Gai discloses 
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a policy server (see FIG. 4, policy server 322) comprising the particular policy feature (see 
FIG. 4, Policy Rule generation engine 414, policy translator 410, and device-specific 
filtering entity; see col. 13, line 61 to col. 14, line 5) including at least one of a destination 
screening feature for a group of subscribers to which the party belongs or a* source address 
screening feature for the group of subscribers (see col. 14, line 1-15, 56 to col. 15, line 55; 
applying source or destination addressing policy rule to a group of users (see FIG. 7A, 
marking users, admin users, executive users, etc.) where a specific user (see FIG. 7A, John 
Doe) belongs; see col. see col. 14, line 10-18). 

In response to applicant's arguments against the references individually, one cannot 
show nonobviousness by attacking references individually where the rejections are based on 
combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re 
Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). In this case, the combined system 
of Buyukkoc and Gai "as a whole" discloses applicant claimed invention. 

The examiner recognizes that obviousness can only be established by combining or 
modifying the teachings of the prior art to produce the claimed invention where there is some 
teaching, suggestion, or motivation to do so found either in the references themselves or in 
the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 
F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988)and/w re Jones, 958 F.2d 347, 21 USPQ2d 1941 
(Fed. Cir. 1992). In this case, it would have been obvious to one having ordinary skill in the art 
at the time the invention was made to provide one of a destination screening feature for a group 
of subscribers to which the party belongs or a source address screening feature for the group of 
subscribers, as taught by Gai in the system of Buyukkoc, so that it would ability to allocate 
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network services and resources by applying high-level quality of service policies; see Gai col. 5, 
line 45-55. Moreover, as set forth above, examiner is not require to show that Buyukkoc 
disclose or suggest a desire to change the routing status database server since the motivation to 
combine can be found " either in the references themselves or in the knowledge generally 
available to one of ordinary skill in the art". In this case, Gai clearly discloses the motivation 
as set forth above. Thus, it is clear that examiner has established a prima facie case of 
obviousness and the above motivation statement satisfy requirement of 35 USC 103. 

In response to applicant's argument that one would not be motivated to incorporate 
this alleged feature into Buyukkoc, the test for obviousness is not whether the features of a 
secondary reference may be bodily incorporated into the structure of the primary reference; nor 
is it that the claimed invention must be expressly suggested in any one or all of the references. 
Rather, the test is what the combined teachings of the references would have suggested to those 
of ordinary skill in the art. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981). 

In response to applicant's argument that the examiner's conclusion of obviousness is 
based upon improper hindsight reasoning, it must be recognized that any judgment on 
obviousness is in a sense necessarily a reconstruction based upon hindsight reasoning. But so 
long as it takes into account only knowledge which was within the level of ordinary skill at the 
time the claimed invention was made, and does not include knowledge gleaned only from the 
applicant's disclosure, such a reconstruction is proper. See In re McLaughlin, 443 F.2d 1392, 
170 USPQ 209 (CCPA 1971). 



22. 



The following responses are generally applicable to all applicant arguments 
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I. Examiner assert the applicant's "policy server" as Buyukkoc's "RSD" as set forth 
above for the following reasons: 

Applicant disclosure (summary of invention) discloses , page 7, lies 1 1-14, 17-18 as 
follows: 

"the present invention is related to an intelligent policy server system and method for 
providing multiple service policy service policy feature or option and for managing bandwidth 
usage in the an ATM network.. . which policy server is also referred as a Multi-Service Control 
Point or MSCP..." 

As recited in above rejection, Buyukkoc discloses in col. 11, line 5-15, as follows: 

"The RSD may be used in conjunction with a number of other innovations. For example, 
the RSD may be used in conjunction with a service control point (SCP) of an Intelligent 
network. An SCP determines an appropriate destination for a call having more than one possible 
destination, such as a call to the 800 number of a large customer that may be routed to one of a 
number of regional service centers, based on factors such as the availability of representatives in 
the various service centers. The RSD may be accessed after an SCP or at the same time as 
an SCP, and the same server may provide RSD and SCP functionality." (Emphasis added) 

Thus, it is clear that Buyukkoc's RSD is the applicant "policy server". 

II) Examiner asserts the applicant's "policy profile having a plurality of policy 
features" as RSD's "connection rules/policy such as connectively information, threshold, 
quality of service, capacity, and/or status of loading/congestion". 

Applicant disclosure discloses , page 7, lies 11-14, 19-21; page 7, line 1-7 as follows: 

"the present invention is related to an intelligent policy server system and method for 
providing multiple service policy service policy feature or option and for managing bandwidth 
usage in the an ATM network... A return message from the policy server determines whether 
a call connection can be made through the network or not... Depending on the triggers 
associated with a signaling message received in the edge switch, a particular feature is invoked 
and executed by the policy server... burst-size limit, class-of-service provisioning, maximum 
concurrent call connections in progress, bandwidth control... are provided as exemplary 
features implemented in a presently preferred exemplary embodiment of the present invention.." 
(Emphasis added) 



Application/Control Number: 09/766,943 
Art Unit: 2616 



Page 42 



As recited in above rejection, Buyukkoc discloses as follows: 

"For each (source, destination) pair in the network, the RSD contains some or all of the 
following information. Depending on the needs and size of the network, a "destination" could be 
a terminating switch or it could be a trunk group or virtual path. Connectivity information 
regarding the set of routes that can be used to interconnect the source and destination. 
Information about alternate routes. Information on the capacity of each route in the network. 
Status of all of the routes in the network. Status could be in the form of free or available 
capacity or utilization on each link, or could be a status indicator such as "lightly loaded", 
"heavily loaded", "extreme congestion". The data needed to manage routing features 
responsible for distributing load to multiple physical destinations based on some rule or 
logic. 

Tables VIMX show a sample RSD for the network of FIGS. 1-5. The Tables show 
information for only a limited number of routes, whereas a real RSD would have more complete 
information. In particular, if there are k routes between each pair of edge nodes and n edge 
nodes in the network, the total number of rows in the Route Status Table (Table IX) is kn(n-l)/2. 
The .alpha.-link, .beta.-link, source, destination, and VPI numbers of Tables VII-IX refer to the 
reference numbers of FIGS. 1-5. 

Table VII contains the current usage of each .alpha.-link. Table VII also contains 
two congestion thresholds for each link, which definethree congestion status ranges - 
referred to as "green," "yellow," and "red," in increasing order of congestion. A status of 
"green" may mean that the route has plenty of capacity left and that new calls can be routed there 
with no difficulty. A status of "yellow" may mean that the link is beginning to get congested and 
that alternate routes should be used if available. A status of "red" may mean to avoid using the 
route if at all possible. For example, if a call arrives and all its possible paths are "red," the call 
may be blocked, depending upon its priority. For example, .alpha.-link 214 has a "green" 
congestion status when the usage is not greater than 1 .4 Gbps, a "yellow" congestion status when 
the usage is greater than 1.4 Gbps and not greater than 1.8 Gbps, and a "red" congestion status 
when the usage is greater than 1.8 Gbps. The current usage of .alpha.-link 214 is 1.312 Gbps, so 
the congestion status is "green." The current usage and congestion status of each link are 
periodically updated. It may be desirable to define different congestion thresholds for different 
links, due to factors such as different capacities and different expected usage volumes. In 
addition, it is preferable to incorporate a safety margin of additional capacity into the thresholds, 
because there is some potential for the information in the RSD to be slightly inaccurate or 
outdated. While Table VII only shows 2 congestion thresholds that define 3 congestion 
status for each link, many more thresholds and congestion status may be defined to allow 
for load balancing, overload control, and priorities for different quality-of-service traffic. 

Table VIII gives the status of the .beta.-links in the network. The information in Table 
VIII is similar to that in Table VII, but applies to .beta.-links instead of .alpha.-links. 

Table IX gives the Route Status Table. The .alpha.-links and .beta.-links associated 
with each route are identified, and the congestion status for each route is maintained. The 
congestion status can be periodically updated from the individual link congestion status 
information in Tables VII and VIII. There are many possible methods for defining Route Status 
based on Link Status. Route Status could be defined as equal to the status on the most congested 
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link in the route, or as an average of the congestion status values for each link in the route. Many 
other definitions are possible, and the present invention is not intended to be limited to any 
particular set of definitions. The Route Status values in Table IX are based on using the status of 
most congested link on the route from Tables VII and VIII..." see col. 9, line 50 (Emphasis 
added). 

"For example, a particular RRSDS 740 may receive information from several edge nodes 
720 regarding the amount of bandwidth that each of the edge nodes uses on a particular .beta.- 
link 715. RRSDS 740 may aggregate this information into a single piece of information that 
represents the total bandwidth used on the particular .beta.-link by those edge nodes 720 that are 
connected to the particular RRSDS 740. CRSDS 730 receives information from each RRSDS 
740, and uses this information to compute the total bandwidth usage on each .alpha.-link and 
each .beta.-link..." see col. 13, line. 36-46. 



In addition, Buyukkoc also discloses 

"A new call arrives at originating switch 270, which determines that the call is destined 
for switch 220. The (origination, destination) information is passed to the RSD, which contains 
the information shown in Tables VII-IX. If there are different possible bandwidth 
requirements for different types of calls, the bandwidth requirement is preferably also 
passed to the RSD. The RSD uses the information in Table IX to determine that the best 
route from switch 220 to switch 270 is B2, with a congestion status of "green." The RSD 
then increments the current usage and congestion status entries for .alpha.-links 224 and 
214 in Table VII and .beta.-Iinks 118 and 116 in Table VIII. Several techniques could be 
used to update the Status Field in Table IX. For example, it could be updated periodically, or 
upon a change in a congestion status. When the call ends, or does not make a successful 
connection, switch 220 and/or switch 270 sends another message to the RSD, and the RSD 
decrements the current usage on the applicable .alpha.-links and .beta.-links..." see col. 17, line 
30-49. 

"Class-of-service on an end-to-end basis may be implemented using the RSD. Using 
Method 8, for example, the originating edge node passes a class-of-service indicator to the RSD 
in addition to the origination and destination information for the call. The RSD uses the Route 
Status in Table IX to give priority to the more important calls. For example, if the Route 
Status is Green, any call can use the route. If the status is Yellow, only high priority calls can 
use the route, and if the status is Red, only the most critical calls can use the route. This example 
may be generalized to additional congestion status levels. Alternatively, the RSD can route only 
a fraction of calls of lower priority on more congested routes. For example, if the Route Status is 
yellow, then a rule might be that 25% of low priority calls and all of the high priority calls can 
use the route..." see col. 18, line 25-40. 



Thus, it clear that the applicant exemplary policy/rule/plan features of a policy profile 
such as "burst-size limit, class-of-service provisioning, maximum concurrent call 
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connections in progress, bandwidth control" clearly disclosed by Buyukkoc's SCP 
policy/rule/administration/guideline/plan/procedure/scheme having plurality of features such as 
bandwidth control/management, class-of-service, and/or loading/congestion of network (i.e. 
concurrent calls connection in progress) as defined in detailed by tables VH-IX. 

III. Examiner asserts applicant's "at least one policy profile" as Buyukkoc's "quality of 
service priority of a request call". 

Buyukkoc discloses: 

"Table VII contains the current usage of each .alpha. -link. Table VII also contains two 
congestion thresholds for each link, which define three congestion status ranges -referred to as 
"green," "yellow," and "red," in increasing order of congestion. A status of "green" may mean 
that the route has plenty of capacity left and that new calls can be routed there with no difficulty. 
A status of "yellow" may mean that the link is beginning to get congested and that alternate 
routes should be used if available. A status of "red" may mean to avoid using the route if at all 
possible. For example, if a call arrives and all its possible paths are "red," the call may be 
blocked, depending upon its priority " in col. 14, line 35-46. 

Thus, it is also clear that applicant "one policy profile" is disclosed by Buyukkoc as 
"quality of service or priority of a new request call" where a new call has a priority associated 
with different quality of service, and RCD invokes "priority or quality-of-service" rule/policy 
such as "green", "yellow" or "red" for establishing a call based on its request. 

Moreover, it also clear that Buyukkoc discloses determining if a particular policy feature 
is to be invoked (i.e. bandwidth control/management, class-of-service, and/or loading/congestion 
of network (i.e. concurrent calls connection in progress) in a policy server/RSD, based at least in 
part on said signaling/request message, and if so, determining in accordance with a 
rule/policy/guide line of bandwidth control/management, class-of-service and/or 
loading/congestion of network (i.e. concurrent calls connection in progress) for request/signaling 
message and as set forth above rejection. 
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Conclusion 

23. THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the mailing 
date of this final action. 

24. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Ian N. Moore whose telephone number is 571-272-3085. The 
examiner can normally be reached on 9:00 AM- 6:00 PM. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Doris To can be reached on 571-272-7629. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would 
like assistance from a USPTO Customer Service Representative or access to the automated 
information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 
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